.TH E1432_SET_DATA_PORT 3 E1432
.SH NAME
.nf
e1432_set_data_port \- Set data port to VME or Local Bus
e1432_get_data_port \- Get current data port
.fi
.IX e1432_set_data_port(3) 3
.IX e1432_get_data_port(3) 3
.SH SYNOPSIS
.cS
SHORTSIZ16 e1432_set_data_port(E1432ID hw, SHORTSIZ16 ID,
                               SHORTSIZ16 port)
SHORTSIZ16 e1432_get_data_port(E1432ID hw, SHORTSIZ16 ID,
                               SHORTSIZ16 *port)
.cE
.SH DESCRIPTION
\fIe1432_set_data_port\fR sets a single channel or group of channels
\fIID\fR, to deliver data either on the VME backplane or on the Local
Bus (for high speed data transfers), or both, depending on the value
of \fIport\fR.

In any mode that uses the Local Bus, the group of E1432s must be
contiguous in one mainframe and positioned immediately to the left of
the module that is to receive the local bus data.  The module on the
extreme left generates data and the others append their data to the
data which is pipelined through them, from left to right.

\fIe1432_get_data_port\fR returns the current value of the data port,
of a single channel or group of channels \fIID\fR, into a memory
location pointed to by \fIport\fR.

This parameter is a "global" parameter.  It applies to an entire E1432
module rather than to one of its channels.  The \fIID\fR parameter is
used only to identify which module the function applies to, and all
channels in that module will report the same value for this parameter.

\fIhw\fR must be the result of a successful call to
\fIe1432_assign_channel_numbers\fR, and specifies the group of
hardware to talk to.

\fIID\fR is either the ID of a group of channels that was obtained with a
call to \fIe1432_create_channel_group\fR, or the ID of a single channel.

\fIport\fR determines the path the E1432 uses to make its data available
to the host.  The following three modes are valid:

\fBE1432_SEND_PORT_VME\fR causes data to be accessed by the host via
the \fBVME bus\fR.  The E1432 module is capable of using D32 and has a
fairly fast VME interface, so this mode is sufficient for many
applications.

\fBE1432_SEND_PORT_LBUS\fR causes data to be transmitted via the
\fBLocal Bus\fR.  This mode is only valid if the E1432 module actually
has a local bus interface, which is option UGV for the E1432 module.
The local bus interface is significantly faster than the VME
interface, and using the local bus frees up the VME bus for other
uses.  However, the local bus only connects modules which are adjacent
to each other, and transfers data only left to right.

Only time data is sent to the local bus, and the enable settings from
\fIe1432_set_enable\fR are completely ignored.

\fBE1432_SEND_PORT_LBUS_EAVES\fR causes data to be transmitted both to
the local bus and the VME bus.  This mode is only valid if the E1432
module actually has a local bus interface, which is option UGV for the
E1432 module.  This mode is typically used to send data to a disk via
the local bus, while allowing a host computer to monitor the data at
the same time.  It is possible to have the E1432 module send time data
to the local bus, while simultaneously FFTing the data and sending the
FFT results to the VME bus.

.SH "EAVESDROP DETAILS"

When doing eavesdrop, the local bus data ignores
\fIe1432_set_data_mode\fR and always uses continuous input data.  The
user uses \fIe1432_set_data_mode\fR to control what data mode
(continuous, overlap, block) is sent to VME.  The "continuous" mode is
valid, but it won't quite be continuous mode because the measurement
won't be aborted if the host can't keep up with the VME data.
Instead, some of the data is skipped over and not sent to the host.

When doing eavesdrop, the user uses \fIe1432_set_enable\fR to control
which channels and data types he is interested in.  These are the
channels and data types which get sent to VME.  The local bus data
ignores \fIe1432_set_enable\fR, and always sends all active input
channels and always sends only raw time data.

When doing eavesdrop, the user uses \fIe1432_set_calc_data\fR to
specify what calculations (resampling, FFT) are done.  This applies
only to the VME data.  The local bus data is always just raw time
data.

When doing eavesdrop, \fIe1432_set_blocksize\fR controls the blocksize
of the data going to VME, but NOT the blocksize of data going to local
bus.  The local bus thruput uses a separate \fIe1432_set_xfersize\fR
to control the local bus blocksize.  NOTE: this is not yet
implemented, currently blocksize applies in all cases.  Non-eavesdrop
local-bus measurements will use xfersize as well.  However, the
default for xfersize will be zero, which will mean to use the value of
blocksize.  This will make things work in a backwards compatible way.

When doing eavesdrop, \fIe1432_set_overlap\fR does not apply to the
local bus data.  The local bus data is continuous with an effective
overlap of 0.  For VME data, \fIe1432_set_overlap\fR is used the same
as it normally is when not doing eavesdrop.

When doing eavesdrop, if the local bus thruput falls behind far
enough, the input data FIFOs will fill up and the measurement will get
a FIFO overflow.  This will abort the measurement (including the VME
eavesdropping) just like it does in any other case of FIFO overflow
with continuous data.

When doing eavesdrop, if the VME data transfer falls behind, then some
of the input data is just skipped over and is not sent to VME.  No
errors are generated.  However, the VME data transfer always gets a
complete scan (a complete block from all enabled channels).  In
addition, the "gap" field in the trailer block is filled in correctly,
so the user will know the gap between one scan and the next.  See
\fIe1432_set_append_status\fR for details about the trailer data.

Because of the above, local bus transfers will have priority over VME
data calculations and transfers.  The module slows down the rate at
which VME receives data blocks rather than cause the local bus thruput
to fall behind.

When doing eavesdrop, normally the VME data is not continuous, and
there is an arm and trigger for each VME data block, just like when
doing a non-local-bus measurement.  These arms and triggers have no
effect on the continuous local bus data, except that the very first
arm/trigger starts the continuous local bus data.  There is no way to
use the local bus data to reconstruct where those arms and triggers
after the first happened, so there is no way to reconstruct exactly
which blocks got sent to VME during the eavesdrop.

If the module is doing order tracking, and therefore is in multi-pass
mode, the data sent to local bus is taken from the top span only.
Also, when the module is doing order tracking, the data sent to local
bus is not oversampled data, even if oversample is turned on.  This is
done so that the data sent to disk is always the same (top span
non-oversampled time data) regardless of the order tracking setup.

.cS
Eavesdrop summary:

                        Local bus data          VME data
-----------------------------------------------------------------------
e1432_set_data_mode     Ignored, local bus      Used
                        data is always
                        continuous

e1432_set_enable        Ignored, local bus      Used to control what is
                        data is all channels,   sent to VME bus
                        raw time data only

e1432_set_calc_data     Ignored, local bus      Used to control what is
                        data is raw time        sent to VME bus
                        data only

e1432_set_blocksize     Ignored                 Used

e1432_set_xfersize      Used                    Ignored

e1432_set_overlap       Ignored, overlap        Used
                        is effectively 0

"Falling behind"        If we fall behind       Skip over input data
                        far enough, a FIFO      in order to catch up
                        overflow will abort
                        the measurement

Priority                Local bus xfer is       Uses only whatever
                        first priority          processing time is
                                                left, even if it means
                                                falling behind

Arm/trigger             First one starts        Used for each block
                        thruput, ignored
                        after that
.cE

.SH "RESET VALUE"
After a reset, \fIport\fR is set to \fBE1432_SEND_PORT_VME\fR
.SH "RETURN VALUE"
Return 0 if successful, a (negative) error number otherwise.
.SH "SEE ALSO"
.na
e1432_set_lbus_mode, e1432_reset_lbus, e1432_set_active,
e1432_set_append_status e1432_set_enable, e1432_set_calc_data,
e1432_set_data_mode, e1432_set_blocksize, e1432_set_xfersize,
e1432_set_overlap
.ad
